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.Titel: Ve'rfahren. zum Debuggen rekonf igurierbarer 

Architekturen 

V 

Beschreibung 

Die vorliegende Erfindung befaflt sich mit Verfahren fur das 
Debuggen von Programmen auf konf igurierbaren. Architekturen. 
Unter einer rekonf igurierbaren Architektur werden u. . a. Bau- 
steine (VPU) mit konf igurierbarer Funktion und/oder Vernet- 
zung verstanden, insbesondere integrierte Bausteine mit einer 
Mehrzahl von ein- oder mehrdimensional angeordneten arithme- 
tischen und/oder logischen und/oder analogen und/oder spei- 
chernden und/oder vernetzenden Baugruppen (im Folgenden PAEs 
genannt) und/oder kommunikativen/peripheren Baugruppen (10), 
die direkt oder durch ein oder . mehrere Bussystem(e) miteinan- 
der verbunden sind. PAEs sind in beliebiger Ausgestaltung, 
Mischung und Hierarchie angeordnet. Diese Anordnung wird im 
weiteren PAE -Array oder PA genannt.- 

Zur Gattung dieser Bausteine zahlen systolische Arrays, neu- 
ronale Netze, • Mehrprozessor-Systeme, Prozessoren mit mehreren 
Rechenwerken und/oder logischen Zellen, Vernetzungs- und 
N^tzwerkbausteine wie z.B. Crossbar-Schalter, ebenso wie.be- 
kannte Bausteine der, Gattung FPGA, DPGA, XPUTER, etc. Hinge- 
wiesen wird insbesondere in die?em Zusammenhang auf die fol- 
genden Schutzrechte desselben Anmelders: P 44 16 881.0-53, DE 
197 81 412.3/ DE 197 81 483.2, DE 196 54 846.2-53, 
DE 196 54 '593.5-53, DE 197- 04 044.6-53, DE 198 80 129.7, 
DE 198 61 088.2-53,. DE 199 80 312.9, PCT/DE * 00/018 69, 
DE 100 36 627.9-33, DE 100 28 397.7, DE 101 10 530.4, 
DE 101 11 014.6, PCT/EP 00/10516, EP 01 102 674.7, ' 
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DE 102 06 856.9, 60/317,876, DE 102 02 044,2, DE 101 29 
237.6-53, DE 101 39 170.6. Diese sind hiermit zu Offenba- 
. rungs zwec ken vollumf anglich eingegliedert . ; - . 

Weiterhin soil angemer.kt werden, dafi die zu beschreibenden 
Verfahren .auch auf Gruppen von mehreren Bausteinen angewendet 
werden kSnnen. Dennoch wird ndchf olgend auf VPU und/oder auf 
„Bausteine x> Bezug genomihen. . Diese Bauteile und deren Betrieb 
sind noch zu verbessern. 

Diq Aufgabe der vorliegenden Erfindung besteht darin, Neues 
fur die gewerbliche Anwendung bereitzustellen. 

Die Losung der Aufgabe wird unabhangig beansprucht . Bevorzug- 
te Ausfiihrungsformen befinden sich in den Unteranspruchen, 

* ! 1 

i . 

i 

1 . ErfindungsgemaBes Verfahren 

Es werden nachf olgend mehrere Verfahren und Hardwareimplemen- 
tierungen vorgestellt, die ein effizientes Debuggen von VPU- 
Systemen ermoglichen. 

t 

Das Debuggen erfolgt in einer bevorzugten Variante entweder 
durch die Verwendung eines entsprechend an eine VPU oder den 
Baustein angeschlossenen Microcontrollers oder durch eine 
Ladelogik nach den Patenten P 44 16 881.0-53, 
DE 196 51 075.9-53,/ DE 196 54 846.2-53, DE 196 54 593.5-53, 
DE 197 57 200.6-33, DE 198 07 872.2, DE 101 39 170.6, 
DE 199 26 538.0, DE 100 28 397.7, die durch Bezugnahrne 
vollumfanglich eingegliedert sind. Wie ersichtlich sein wird, 
sind aber auch andere Hardware-Varianten verwendbar. 




Folgende grundlegende Verfahren sollen alternativ und/oder 
gemeinsam dabei angewehdet werden: - 

5 1.1 Erkennen einer Debug-Bedingung 

1.1.1 Bedingung 

Durch den Programmierer wixd beispielsweise innerhalb des De- 
bug-Tools eine oder mehrere Bedingungen festgelegt, die das - 
10 Debugging starten (vgl. Breakpoint nach dem Stand der Tech- 
^ nik) . Das Auftreten der Bedingungen wird zur Lauf zeit in der 
* VPU und/oder einem beliebigen mit der VPU datenaustauschenden 
Gerat festgestel.lt. Dies geschieht beispielsweise durch das 
Auftreten von bestimmten Datenwerten bei bestimmten Variablen 
15 und/oder bestimmten Triggerwerten bei bestimmten PAEs. 

1.1.2 Vorbedingung ' 

Im Optimalf all ' kann . eine .bestimmte Bedingung g'emafl o'.g. Defi- 
20 nition bereits mehrere Takte vor dem Eintreffen der Debug- 
. m Bedingung durch den Programmierer festgelegt werden. Dadurch 
werden bestimmte Latenz-Probleme, die im folgenden diskutiert 
werden, von vornherein ausgesc.hlossen . 

25 • Es sollen im folgenden zwei grundlegende Art en des Debuggings 
fur VPUs diskutiert 'werden, wobei die jeweils bevorzugt anzu- 
wendende Methode ' von der Wahl des Compilers abhangt : 
Fur Compiler, die Code auf Basis von instantiierten Modulen 
einer Hardwarebeschreibungssprache (oder ahnlichen Spra.che) 

30 generieren, kann sich besonders die im folgenden beschriebene 
Method© -A eignen. 
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Fur Compiler ahnlich DE.101 39 170.6 unci Zusatzanmeldungen, 
die komplexe .Instruktionen erzeugen und nach einem VLIW- 
ahnlichen Verfahren generieren.,- eignet sich besonders die im 
folgenden beschriebene Methode B. Grundsatzlich ist fur den 
5; Betrieb einer VPU bder eines entsprechenden Bausteins als 
Prozessor od.er Coprozessor Methode B die bevorzugt anzuwen- 
dende . 

Es wurde erkannt, dass 'insbesondere .die Verwendung beider Me- 
10' thoden A und B gemeinsam zu den besten und transparentesten 
Debuggingergebnissen fuhrt. Insbesondere kann je nach Tiefe 
des zu debuggenden Fehlers zunachst unter Zuhilf enahme der 
schnellen Debuggingmethode B debuggt werden und nach hinrei- 
chende Lokalisierung des Fehlers sodann per Methode A die De- 
15 tails in der "Tiefe" analysiert werden. 



Methode A 




20 2.1 Grundprinzip 

■ Nach dem Auftreten einer (Vor) Bedingung wird die VPU angehaii- 
ten. Danach werden die relevanten Debug-Inf ormatipnen aus den 
PAEs an das Debug-Programm tibertragen. Die relevanten Debug- 
Inf ormationen wurden zuvor durch den Prograinmierer - innerhalb 
25 des Debug- Programmes festgelegt. Nach Auslesen aller relevan- 
ter Debug-Inf ormationen wird der nachste Takt ausgef uhrt und 
erneut die relevanten Debug-Inf ormationen ausgelesen. Dies 
wiederholt sich solange, bis der Prograinmierer den Debug- 
Vorgang abbricht. Anstelle des Anhaltens der VPU sind eventu- 
30 ell andere Verfahren denkbar. So. konnen fur eine gegebene Ab- 
folge von Takten wiederholt Daten zum Auslesen bereitgestellt 
werden, sofern dies schnell genug moglich ist. 
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2.2 Unterstiitzung durch die Hardware 

2.2.1 Auslesen der Register 

Wesentlich fur die Funktionsweise des Debuggers ist die M6g~ 
5 lichkeit, durch eine ubergeordnete Einheit (im folgenden De- 
bugProzessor (DB) genannt) , also beispielsweise eine CT oder 
Ladelogik, einen anderen extern angeschlossenen (Host) Pro- 
zessor .oder einen reservierten Arraybereich, die internen Da- 
tenregister und/oder Statusregister und/oder' Zustandsregister 
10 und ggf . je nach Implementierung weitere relevante Register 

•und/oder Signale aus den PAEs und/oder dem Netzwerk zuruckzu- 
lesen bzw. dies nur fur ausgewahlte Register bzw. Signale zu 

tun (zusammengefaJit im folgenden als Debuginf ormation be- 

» 

zeichnet) . Eine derartige Moglichkeit ist z. B. mit der in 
15 der PCT/DE 98/00334 gescha.f f enen Verbindung zwxschen der 

Ladelogik und dem Datenbus einer PAE (PCT/DE 98/00334 0403, 
Fig. 4) realisierbar . 1 

Es soil ausdrucklich angemerkt sein, dafi auch serielle Ver- 
20 fahren zum Auslesen' dei Register verwendet werden konnen. 

Beispielsweise kann JTAG-gewahlt werden und der DB uber die- 
ses Verfahren ggf. auch als externes seperates und evtl. auch 
ma rkt lib riches Gerat (z. B. Firma Hitex, Karlsruhe) ange- 
schlossen sein. 
25 % 

Da bevorzugt auf samtliche Register, oder zumindest eine er- 
heblich Anzahl derer, durch den Debugger schreibend und/oder 
lesend' zugegriffen werden kann, kann optional und bevorzugt 
ein* wesentlicher Teil der (seriellen) Verkettung de'r Register 
30 zu Testzwecken (Scan-Chain) fur die Produktionstests des 

Chips- entf alien. Die Scan-Chain wird normalerweise dafiir ver- 
wendet, urn alle Register innerhalb eines Chips wahrend der .. 
Produktionstests mit Testdaten vorladen, zu konnen und/oder 
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die Inhalte der Register, zu- Test zwe.cken wieder zuruckzulesen . . 
Das Vorladen und/oder : Zuruckles^en geschieht dabei typischer- 
weise durch Testsysteme (z.B.'SZ Testsysteme, Amerang) 
urld/oder gemafi den in der DE 197 57 200'. 6-33 beschriebenen 
Verfahren. Die Scan-Chain benotigt dazu eirien ziisatzlichen 
nicht unerheblichen Hardware- und Flachenauf wand fur jedes 
Register. " Dieser kann. nunmehr, 'zumindest fur die Register, 
die debugbar sind, entfallen, wenn - wie erf indungsgemali vor- 
gpschla'gen - die Produktionstestanlagen tiber geeignete 
Schnittstellen (z.B. parallel, seriell, JTAG, etc.) Zugrift 
auf die Register erhalten.- 

2/2.2 Anhalten oder Verlangsamen des Taktes 

Durch das Auftreten von Bedingung und/oder Vorbedingung kann 
der Takt entweder angehalten oder verlangsamt werden, urn hin- 
reichend Zeit zum- Auslesen zur Verfugung zu stellen. Ausge- 
lost wird dieser Debugbeginn insbesondere entweder direkt 
durch eine PAE-, die die. (Vor) Bedingung (en) berechnete oder 
durch eine iibergeordnete. Ei'nheit (z. B. Ladelogik/CT, Host- 
prozessor) aufgrund beliebiger Aktionen, beispielsweise durch 
die Information, dafl an einer PAE eine (Vor) Bedingung auftrat 
und/oder durch eine Aktion innerhalb des DebugProzessors 
und/oder durch >ein beliebiges Programm und/oder eine beliebi- 
ge externe/periphere Quelle. Zum Informieren stehen Trigger^ 
mechanismen entsprechend P 44 16 881. 0-53,'- DE 196 51 075. 9-. 
53, DE 197 04 728.9, DE 198 07.872.2, DE 198 09 .640.2, DE 100 
28 397.7 zur Verfugung. Alternativ kann beinT Debuggen der 
Takt generell verlangsamt werden. Sollen nur Arrayteile de- 
buggt werden, kann eine partielle Heruntertaktung vorgesehen 
werden. 
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Sofern der Takt verlangsamt wird, muss durch den Debugprozes- 
sor innerhalb.des verlangsamt en Zyklus des Verarbeitungstak- 
tes alle relevante Debug-Inf ormation aus den PAEs ausgeleseri 
werden, Dazu ist es sinnvoll und bevorzugt, den Takt nur par- 
's tiell zu verlangsamen, also den Arbeitstakt zu senken oder 
• anzuhalten, aber den Takt fur den Auslesemechanismus weiter 
fortzuf ahren. Des weiteren Ist es sinnvoll und bevorzugt, ge- 
nerell die Register zum Datenerhalt . mit Takt zu versorgen. • ■ 

10 Nach dem Anhalten .des Taktes kann ein Single-Step Modus rea- 
lisiert werden/ d.h. der Debugprozessor halt den Verarbei-^ 

tungstakt so lange an, bis er alle Debug-Inf ormation ausgele- 

> 

' sen hat. Danach startet er den Verarbeitungstakt wieder fur 
einen Zyklus und halt ihn ! erneut' bis nach dem Auslesen aller 
15 felevanten Debug-Inf ormationen an. 

• Der Auslesetakt und der Takt des Debug-Prozessors sind bevor- 
zugt unabhahgig vom Verarbeitungstakt der PAEs, so dafi die 
Datenverarbeitung vom Debugging - und insbesondere Auslesen der 
20 Debug-Inf ormation getrennt ist. 

Hardwaretechnisclx wird das Anhalten oder Verlangsamen des 
Taktes durch Methoden nach dem Stand der Technik, wie bei- 
spielsweise Gated-Clocks und/oder PLLs und/oder Teller oder 
25 andere Verf ahren erreicht. Diese Mittel' werden bevorzugt an 
. geeigneten Stellen (Knoten) innerhalb des Clock-Trees einge- 
fugt, so daB eine globaie Taktsteuerungen der jeweils tiefer- 
liegenden Zweige realisierbar ist. Die Heruntertaktung nur 
von ausgewahlten Arrayteilen ist in den unter Bezug genomme- 
30 nen Anmeldungen des- vorliegenden Anmelders offenbart. 



Besonders bevorzugt ist das Versenden einer Taktsteuer- 
Inf ormation von einer iibergeordneten Einheit (z.B. Ladelo- 
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gik/CT, Hpstpro'zessor) an samtliche bzw. samtliche zu debug- 
genden PAEs. Dies karin bevorzugt iiber das Konf igurationsbus- 
system erfolgen. Die Taktsteuerinf.ormation wird dabei typi- 
scherweise gebroadcastet iibertragen, d.h. alle PAEs erhalten . 
5 dieselbe Information. 

Beispielsweise konnen f olgende Taktsteuerinf ormationen imple- 
rrtentiert sein: 

10 STOP: Der Arbeit stakt wird ang'ehalten. * 

SLOW: Der Arbeitstakt wird verlangsamt . 

STEP: Exakt ein Verarbeitungsschritt (Single Step Modus) 

wird ausgefuhrt und dann der Arbeitstakt wieder an- 
gehalteri. 

15 STEP(n): n Verarbeitungsschritte werden ausgefuhrt und dann 
der Arbeitstakt wieder angehalten. 
GO: Der Arbeitstakt lauft normal weiter. 

Es soli insbesondere erwahnt sein., dass das Verfahren der 
20 Taktabschaltung und/oder Verlangsamung ebenso eingesetzt wer- 
den kann, urn den Stromverbrauch zu reduzieren. Sofern tempo- 
rar keine Rechtenleistung benotigt wird, kann ein "Sleepmode" 
beispielsweise durch das Abschalten des Arbeitstaktes (STOP) 
oder durch spezielle Befehl.e (SLEEP) realisiert werden. Wird 
25 riicht die voile .Rechenleistung benotigt, kann der Takt durch 
die Verwendung von SLOW verlangsamt werden und/oder temporar 
durch STEP(n) ausgesetzt werden. Insoweit ist das Verfahren 
optional und/oder zusatzlich zu den in der DE 102 06 653.1 
beschriebenen Verfahren zur Reduzierung der Verlustleistung 
30 - einsetzbar . 

Ein Problem des Broadcastings von Taktsteuerinf ormationen ist 
die Obertragungszeit des Broadcastes durch das Array aus 
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PAEs. Die Obertragung kann' bei hoheren' Taktf requenzen nicht 
innerhalb eines Arbeitstalctes erfolgen. Es ist aber zwingend 
notwendig, dass samtliche PAEs zur gleichen Zeit auf die 
Taktsteuerinf ormationen reagieren. Bevorzugt wird die Takt- 
steuerinf ormation daher uber ein gepipelintes Bussystem ahn- 
lich des in DE 100 28 397,7 beschriebenen CT-Bussystems tiber- 
tragen. Weiterhin wird ein Zahlenwert ( LAT VAL y den Taktsteue- 
rinf ormationen hinzugefugt der gleich oder grofier der maxima- 
len Lange der Pipeline des Bussystems ist- In jeder Pipeli- 
nestufe wird taktweise der Zahlenwert dekrementiert (Subtrak- 
tioh von 1). Jede PAE, die die Taktsteuerinf ormation erhalt, 
dekrementiert im weiteren den Zahlenwert mit jedem'Takt. Da- 
mit ist sichergestellt, dass der Zahlenwert in dem gepipelin- 
ten Bussystem 6 und den PAEs, die die Taktsteuerinf ormation be- 
reits empfangen haben, immer exakt gleich, ist. Erreicht der 
Zahlenwert den Wert 0, ist sichergestellt, daB alle PAEs die 
Taktsteuerinf ormation erhalten haben. Jetzt tritt die Takt-' 
steuerinf ormation in Kraft und das Verhalten des Taktes wird 
entsprechend mbdif iziert . ' 

'Durch das beschriebene Verfahren entsteht eine weitere La-, 
tenzzeit (Latency). Diese kann beispielsweise durch , die' nach- 
folgend beschriebene Registerpipeline zusatzlich abgef angen ' 
werden, oder, wie besonders bevorzugt, durch die Definition 

.der (Vor) Bedingung abgef angen werden, indem die (Vor)Be- 
dingung soweit vorgeset zt wird, daii die Latenzzeit bereits 
berucksichtigt ist. 

Es soil besonders erwahnt werden, dafi die Latenzzeit im Sin- 
gle-Step. Modus vernachlassigba'r ist, da sie nur bei der Ab- 
schaltung es Taktes (STOP) e.ine Rolle spielt. Da der Befehl 
STEP immer nur exakt einen Schritt ausfuhrt, kommt es wahrend 
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des Single-Step Betriebes durch keinerlei , Verf alschung (Ver- 
zogerung) der Debugdaten durch die Latenzzeit. 

5 2.2.3 Registerpipeline' zum Ausgleichen der' Latency 

Bei.hoheren Betriebsf requenzen kann es zu einer Latenzzeit 
• zwischen dem Exkennen des Debugbeginns und dem Anhalteh oder 
Verlangsamen des Taktes kommen. Diese Latenzzeit ist exakt 
vorherbestimmbar, da die Position der verzogernden Register 
10 in der- VPU durch Hardware und/oder den zu debuggenden Algo- 

•rithmus definiert und durch 'den Debugger daher exakt bere- 
chehbar ist.. 

Durch die* Latenzzeit verschieben sich jedoch die dem Debug- 
15 ' Prozessor zur Verfiigiing gestellten Inf ormationen derart, daft 
■ nicht mehr die korrekten Debuginf ormationen ausgelesen werden, 
konnen. Bevorzugt wird dies durch ein entsprechendes Festle- 
gen der (Vor ) Bedingung durch den Programmierer gelosf. Optio- 
nal kann durch das Einfugen einer mehrstuf igen . Registerpipe-, 
20 line, die die Debuginf ormation in jedem Takt urn ein Register 
weiter ubertragt, der Debugprozessor a'uf so viele. Takte an . 
Debuginf ormationen' zuriickgreif eh, wie die Registerpipeline 
iahg ist. Die Lange der Registerpipeline ist so auszulegen, 
daii sie der .maximal zu erwartenden Latenz entspricht. Auf- 
25 grund der exakten Berechenbarkeit der Latenzzeit ist es nun- 
mehr dem Debug-Programm moglich, die zeitlich kofrekte, rele- 
vante Debug-Inf ormation aus der Registerpipeline auszulesen*. 

Ein auftretendes Problem bei der Verwendung von Registerpipe- 
■ 30 lin.es ist r daft diese verhaltnismafiig lang und damit, bezogen 
auf die fUr die Realisierung notwendige Siliziumf lache, teuer 
sind. 
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2.3 Sichtbaare Debug- Inf orma tionen 

Bei dieser Methode wird ira wesentlichen nach Auftreten der 
(Vor)Bedingung debugt, da erst danach der Takt verlangsamt 
oder angehalten wird und das" Auslesen der Debug-Inf ormation 
erfolgt. Debug-Inf ormationen, die vor dem Auftreten der 
(Vor) Bedingung liegen,' sind daher zunachst nicht sichtbar. 

. Es ist jedoch, wenngleich auch unter Verlust. an Arbeitslei- 
. stung, moglich eine VPU sofort vom Start einer Applikation an 
mit verlangsamten Takt oder Single-Step-Modus zu betreiben. ' 
Vom Start an werden die relevanten Debug-Inf ormatidnen vom 
Oebug-Prozessor ausgelesen. 

3. Methode B 

3 . 1 Grundprinzip 

Relevante Debug-Inf ormationen aus den Speichereinheiten, die 
gemafi P 44 16 881.0-53, DE 196 54 846.2-53, DE 199 26 538.0, 
DE 101 39 170.6 und deren Zusatzanmeldungen, DE 101 10 530.4, 
die Anwendungsdaten und Zustande eines bestimmten Arbeits- 
schrittes beinhalten, werden an dais Debug-Programm Ubertra- 
gen. Diese Speichereinheiten, nachfolgend auch Arbeitsspei- 
cher genannt, arbeiten im Maschinenmodell nach der P 44 16' 
881.0-53, DE 196 54 846.2-53, DE 101 39 170.6 und deren Zu- 
satzanmeldungen, DE 199 26 538.0, DE 101 10 530.4 quasi als 
Register zur Speicherung yon Daten, die' innerhalb eines Kon- 
figurationszykluses im PA. oder Teilen des ' PAs berechnet wur- [ 
den. Es wird insbesondere auf die Patentanmeldung DE 101 39 
170.6 und deren Zusatzanmeldungen verwiesen, in der die Ver- 
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wendung der Speichereinheiten als Register (REG) zur'Reali- 
sierung eines Prozessormodells detailliert beschrieben ist. 
Die DE 101 39 170.6 und deren Zusatzanmeldungen sind zuOf- 
f enbarungszwecken vollumf anglich eingegliedert . Eine Spei- 
chereinheit besteht dabei aus einer beliebigen Anordnung und 
Hierarchie von unabhangigen und abhangigen Speichern. Es ist 
moglich, gleichzeitig mehrere unterschiedliche Algorithmen 
auf dem PA (Processing Array) auszufiihreri, die dann unter- 
schiedliche Speicher verwenden. 



Wesentlich fur die Anwendung dieser Methode ist, dafl Daten 
und/oder algorithmisch relevante Zustande in die den PAEs zu- 
* . geordneten Speichereinheiten abgelegt sind, wobei eine Spei- 
chereinheit jeweils zumindest derart dimensioniert ist, daft 
15 alle relevanten'Daten und/oder Zustande eines Zyklus gesp'ei- 
chert werden konnen; hierbei kann die Lange eines Zyklus 
durch die GrSfie der S'peichereinheit bestimmt sein und ist es 
bevorzugt auch (vgl. DE 196 54 846.2-53) • Mit anderen Worten 
wird die Zykluslange der Hardware angepalit. 
20 . 

Unterschiedliche Daten und/oder Zustande werden derart in die 
Speichereinheiten gespeichert , dafi diese eindeutig dem Algo- 
rithmus zugeordnet werden konnen. Dadurch kann der Debugger 
die .relevanten Daten und/oder Zustande (Debug-Inf ormation) • 
25 eindeutig identif izieren. 

Die relevanten' Debug-Inf ormationen konnen - insbesondere auch 
vorab durch den Programmierer ' innerhalb des Debug-Pro- 
grammes festgelegt werden. Diese Debug-Inf ormationen werden 
30 aus 'den Speichereinheiten ausgelesen. Daz.u stehen unter- 
schiedliche Methoden zur Verfugung; einige Moglichkeiten wer- 
den nachfolgend naher beschrieben. Nach dem Auslesen aller 
relevanter Debug-Inf ormationen wird der nadhste Konfigurati- 
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onszyklus ausgeftihrt und erneut die relevanten Debug-Infor- 
mationen aiisgelesen. Dies wiederholt sich so lange, bis der 
Programmierer/ Debugger den Debug-Vorgang abbricht. 

Mit anderen Worten werden die relevanten Daten und/oder Sta- 
tusinformationen nicht taktweise, sondern konf igurationsweise 
an den Debugger iibertragen.' Dies geschieht aus den Spei- 
chereinheiten, die mit den Registern einer CPU vergleichbar 
sind. 



3.2 UntersfcirtzTing durch die Hardware 1 

Wesentlich far die Funktionsweise des Debuggers ist die Mog- 
lichkeit, durch die CT oder einen anderen. extern angeschlos- 
senen Prozessor (im Folgenden DebugProzessor (DB) genannt) , 
die beispielsweise. auch interne (n) Arbeitsspeicher der VPU zu 
leseh. Eine derartige Moglichkeit ist z.B. durch den AnschluB 
der CT an die Arbeitsspeicher zum Vorladen und Lesen der Da- 
ten und/oder durch die in . der DE 199 26 538.0 beschriebene • 
Verfahren zum Herausschreiben der internen Speicher an exter- 
ne Speicher gegeben. In einer mogliche Ausgestaltuhg kann auf 
Arbeitsspeicher durch verschieden Verfahren nach dem Stand 
der Technik (z.B. Shared Memory, Bank Switching) der art vom 
DebugProzessor zugegriffen werden, dass der Datenaustausch 
mit dem DB weltestgehend unabhangig yon einer weiteren Daten- 
verarbeitung in der VPU erfolgen kann. 

In einer moglichen Ausgestaltung kann z. B. entsprechend Me- 
thode A durch eine oder mehrere der vorstehend beschriebenen 
Maflnahmen der Takt der VPU zum Auslesen der Speicher gegebe- 
nenfalls entweder entsprechend verlarigsamt oder angehalten 
werden und/oder gegebenenfalls im Single-Step-Modus betrieben 
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werden. Dabei kannje nach Implementierung der Arbeitsspei- ' 
cher, z. B. beim Bank-Switch-Verf ahren, auf einen besonderen 
Eingriff in den Takt verzichtet werden. Typischerweise ge- 
schieht das Anhalten Oder Verlangsamen des Taktes nach Metho- 
de B und das Auslesen, und/oder Kopieren und/oder Umschalten 
der Arbeitsspeicher nur, ' wenn ein Datenverarbeitungszyklus 
bzw. Konf igurationszyklus beendet ist. 

Mit anderen Worten ist ein wesentlicher Vorteil von Methode 
B, dass keine besondere Unterstutzung durch die Hardware er- 
forderlich ist. 

In einer moglichen Ausgestaltung mufi ein DB. lediglich Zugriff 
auf die. Arbeitsspeicher besitzen. In einer besonders zu be- 
vorzugenden Ausgestaltung geschieht der Zugriff auf die Ar- 
beitsspeicher durch eine geeignete Konf iguration der VPU, die. 
dadurch die Arbeitsspeicher selbstandig und ohne Modif ikatibn . 
ausliest und an einen DB ubertragt . 

3.3 Zugriff auf Debug-Inf ormation 

In der P 44 16 881.0-53, DE" 196 54 846.2-53, DE 101 39 170.6, 
DE 199. 26 538.0 sind Datenverarbeitungsverf ahren beschrieben, 
bei denen zyklisch eine Menge an Operationen auf einen rekon- . 
figurierbaren Datenverarbeitungsbaustein 'abgebildet werden. 
In jedem Zyklus wird eine Mehrzahl von Daten berechnet, die 
von einer peripheren Quelle und/oder einen interhen/externen 
Arbeitsspeicher stairanen und an eine periphere Quelle und/oder 
einen internen/externen- Arbeitsspeicher geschrieben werden. 
Dabei kSnnen,. jeweils unterschiedliche und/oder vor allem meh- 
rere unabhangige Arbeitsspeicher gleichzeitig verwendet wer- 
den. Beispielsweise kdnnen in diesem Datenverarbeitungsver- 
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•fahren die Arbeitsspeicher oder ein Teil der Arbeitsspeicher 
als Registersatz dienen. 

Nach der DE 101 39 170.6 und der DE 199 26 538.0 warden dabei 
samtliche Daten und Zustaride, die fur die weitere Datenverar- 
.beitung . relevant sind, in die Arbeitsspeicher abgelegt 
und/oder aus selbigen gelesen. In einem bevorzugten Verfahren 
werden fur die weitere Datenverarbeitung irrelevante Zus.tande 
nicht gespeichert. 

Die Unterscheidung zwischen relevartten und irrelevanten Zu- 
standeri soli an folgendem Beispiel aufgezeigt werden, es soil 
zu Of fenbarungszwecken dabei insbesondere auf die Ausfiihrun- 
gen in der DE 101 3 9 170.6 verwiesen werden: 

'• 

Die Zustandsinfprmation eines Vergleichs ist beispielsweise 
far die weitere Verarbeitung der Daten wesentlich, da dieser 
die auszufuhrenden Funktlonen bestimmt. 

Ein sequenzieller Dividiere.r entsteht beispielsweise dutch 
Abbildung eines Divisionsbef ehles auf eine Hardware, die nur 
die sequenzielle Division unterstut zt . Dadurch entsteht ein 
Zustand,. der den Rechenschritt innerhalb der Division kenn- 
zeichnet. Dieser Zustand ist irrelevant, da ftir den Algorith- 
mic nur das Ergebnis (also die ausgefuhrte Division) erfor- 
deriich ist. In diesem Fall werden also* iediglich das Ergeb- 
nis und die Zeitinformation (also die Verf iigbarkeit ) beno- 
tigt. 

Die Zeitinformation ist .beispielsweise in der VPU-Technologie 
nach P 44 16 881.0-53, DE 196 51 075.9-53, DE 199 26 538.0 
durch das RDY/ACK Handshake erhaltlich . - Hierzu ist jedoch be- 
sonders anzumerken, dafi das Handshake ebenfalls keinen rele- 
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vanten Zustand darstellt, da es lediglich die Giiltigkeit der 
Daten signalisiert , wodurch sich wiederum die verbleibende 
relevate Information auf die Existenz gultiger Daten redu- 
ziert. . 

In der DE 101 39 170.6 wird eine Unterscheidung zwischeh lo- 
kal und global relevanten Zustanden aufgezeigt:. 

lokal: Der Zustand ist nur innerhalb e.iner einzigen abge- 
•schlossenen Konf iguration relevant 1 ■ Daher muli der Zustand 
nicht zwingend gespeichert werden. 

global:. Die Zustandsinf ormation wird fur mehrere Konfigura- 
tionen benOtigt. Der Zustand mufi gespeichert werden. 

Es ist nunmehr denkbar, dafi der Programmierer, einen lokal • re- 
levanten Zustand debuggen will, der nicht in den Speichern 
abgelegt ist. In diesem Fall kann die Applikation dahingehend 
modifiziert werden, dafi eine Debug-Konf iguration en'tsteht 
(Equivalent zum Debug-Code von Prozessoren) , die eine Modifi- 
kation zum "normalen" Code der Applikation derart aufweist, 
dafi dieser Zustand zusatzlich in die Speichereinheit ge- 
schrieben und damit dem Debugger . zur .Verftigung ges'tellt wird. 
Dadurch. entsteht eine Abweichung zwischen Debug-Code und tat- 
sachlichem Code, die zu einem unterschiedlichen Verhalten der 
Codes f iihren kann . 

In einer daher besonders bevorzugten Ausfahrung wird keine 
Debug-Konf iguration verwendet. Vielmehr wird die zu debuggen- 
de Konf iguration derart terminiert, dass die fur Debugging- 
zwecke zusatzlich erf orderlichen Daten die Terminierung aber- 
dauern, d.h. weiterhin gul.tig in den entsprechenden Speicher- 
steilen (REG) (z.B. Register, Zahler, Speicher) verbleiben. 
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. : Wenn die zu debuggende Konf iguration derart terminiert wird, 
\dafidie fur Debugging-Zwecke . zusatzlich erf orderlichen Daten 
die T.erminierung uberdauern, ist es moglich, ein De'buggen - 
einfach dadurch du'rchzuf uhren, dafi nicht die nachste, bei 
5 normalem Programmablauf erf orderliche Konf iguration geladen 
wird, sqndern stattdes.sen eirie Konf iguration, iiber welche die. 
zu den Debugging-Zwecken erf orderlichen Daten in' die. Debug- 
Einheit bzw. das Debug-Mittel ubertragen werden. Es sei dar- 
auf hingewiesen, ,daI5 bei einem solchen Debuggen auch im spa- 
10 teren Ablauf des Programmes stets die zu Debug-Zwecken erf or- 
derlichen Daten mit abgespeichert werden' konnen, wodurch si- 
chergestellt ist, dafi das spater ausgefiihrte Prograirati in ex- 
] akt der Weise einem Debug-Prozefi unterworfen wurde wie erfor- 
derlich. Nach Auslesen der Debug-Inf ormation durch eine dedi- 
15 zierte Debug-Kohf iguration kann dann mit der normalen Pro- 
grammausfiihrung fortgefahren werden. 

Eine Konf iguration wird geladen, diese verbindet die REG in 
geeigneter Weise und definierter Reihenfolge mit einem oder 
20 mehreren globalen Speictier (n)', auf die der DB Zugriff hat 
(ziB.. Arbeitsspeicher) . 

Vorgeschlagen wird also, daii eine Konf iguration geladen wird, 
diese die REG in geeigneter Weise verbindet und in definier- 
25 ter Reihenfolge mit einem oder mehreren globalen Speichern 
verbindet, auf die der DB Zugriff hat (z. B.' Arbeitsspei- 
cher) . 

Die Konfiguration kann beispielsweise Adressgeneratoren ver- 
30 wenden, urn auf den/die globalen Speicher zuzugreifen. Die 

Konfiguration kann beispielsweise Adressgeneratoren verwen- ■ 
den, urn auf als Speicher ausgestaltete REG zuzugreifen. Ent- 
sprechend der 'konf igurierten Verbindung zwischen den REG wer- 
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den die Inhalte der REG in einer def inierten. Reihenf olge in ' 
den globalen Speicher geschrieben, .wobei die jeweiligen 
Adressen von Adressgeneratoren vorgegeben werden. Der Adress- 
generator generiert die Adressen fur den/die globalen Spei- 
5 cher(n) derart, 'dafi die beschriebenen Speicherbereiche (DEBU- 
• GINFO) der entfernten zu debuggenden Konf iguration eindeutig 
zugeordnet werden konnen. . 

Das Verfahrfen entspricht dem Kontext-Switch in DE 102 06 . 
10 653.1 und DE 101 39 170.6, die zu Of f enbarungszwecken vollum- 
fanglich eingegliedert sind. 

Der DB kann- nunmehr auf die Daten innerhalb eines ihm zugang- 
lichen Speidherbereiches (DEBUGINFO) zugreifen. Soli das De- 
15 bugging mitt els eines Single-Step Verfahrens durchgefuhrt 

werden, kann nach jedem single step einer zu debuggenden Kon- 
figuration ein Kontext-Switch derart durchgefuhrt werden, 
dass samtliche Daten erhalten bleiben und die . zu debuggende 
Information aus den REG in einen Arbeitsspeicher geschrieben 
20 wird. Sodann wird wiederum unter Erhalt der Daten die zu de- 
' buggende Konf iguration wieder konf iguriert und fur einen wei- 
teren single step ausgefiihrt. Dies geschieht fur jeden zu de- 
W buggenden single step der zu debuggenden Konf iguration . Auf 

die Moglichkeit eines Debugging unter Verwendung der als • „Wa- 
25 ve-Rekonf iguration" bekannten Prinzipien sei hingewiesen, 

3.4 Sichtbare Debug- Informationen 

30 Ein Debuggen vor der (Vor) Bedingung kann vergleichsweise ein- 
fach und ohne grofie Perf ormance-Verluste durchgefuhrt werden, 
da die benotigten Debug-Inf ormationen in Arbeitsspeichern 
verfiigbar sind. Durch das (Jbertragen der Arbeitsspeicher in 
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andere Speicherbereiche, auf die der DB bevorzugt direkten 
Zugriff hat, kann' die Debug-Inf ormation einfach sicherge- 
stellt werden. Eine- noch schnellere Methode 1st, -.die Arbeits- 
speicher durch ein Bank-Switching- Verf ahren (nach dem Stand 
der Technik) derart zwischen den einzelnen Konf igurat'ionen 
umzuschalten, daft die Debug-Inf ormation in einer jeweils neu- 
en Bank liegt. Das Umschalten kann sehr zeitoptimierend, im 
Optimalfall sogar ohhe Auswirkung* auf die Verarbeitungsleir- 
stung erfolgen. 

Es ist bereits offenbart worden, dafi bei einer ,VPU Daten 



blockweise iri'einen Speicherbereich ubertragen werden konnen. 
Dieser kann auch auBerhalb des eigentlichen PA liegen 
. und/oder einen Dual-Ported-RAM odier dergleichen aufweisen, so 
15 daii es moglich ist, auf die eingeschriebene Information, von 
auflen leicht zuzugreifen. ' • 



4 . Funk-bxonsweiise des Debuggers 



Das Debugger-Programm selbst kann auf einem DB auBerhalb des 
PAs ablaufen. Alternatiy dazu kann eine VPU selbst den DB 
darstellen, entsprechend der Methoden, die bei Prozessoren 
angewehdet .werden . Dazu kann ein Task- oder Kontextswitch 
25 (SWITCH) entsprechend den Ausf uhrungen in PACT11 ausgefiihrt 
werden. Die Debuginf ormationen des zu debuggenden Programmes 
werden bei einem SWITCH zusammen mit den relevanten Daten ge- 
sichert und das Debugger Programm geladen, das die Inf orma- . 
• tionen. auswertet uncj/oder interaktiv mit dem Programmierer 
30 verarbeitet. Danach wird erneut, ein SWITCH durchgefuhrt (bei 
welchem die relevanten Inf ormationen des Debuggers gesichert 
werden) und das zu debuggende Programm wird weitergef iihrt . 
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Es sei auch erwahnt/ dafi 'als Debugger ein. Prozessor-T'eil- 
bereich vorgesehen werden kann. 

Die Debug-Information wirci vom Debugger entsprechend Methode 
5 A und/oder B gelesen und in einen von der Datenverarbeitung . 
separaten Speicher tind/oder Speicherbereich ge'speichert , auf 
den der DB bevorzugt direkten Zugriff besitzt.. Durch das. De- 
bugger-Programm werden die Breakpoints und (Vor) Bedingungen ■. 
definiert. Ebenfalls kann das Debugger-Programm die Kontrolle 
10 uber die Ausfuhrung der Applikation, insbesondere den Auafuh- 
rungsstart und das Ausf uhrungsende ubernehmen. , 

Der. Debugger stellt dem Programmierer eine geeignete Arbeits- 
umgebung zur Verfugung mit ggf . graphischer Oberflache. In 

15 einer besonders bevorzu'gten Ausfuhrung ist' der Debugger in 

eine komplexe ■ Entwicklungsumgebung. integriert und tauscht mit-. 
dieser Daten und/oder Steuerinf ormation aus. Insbesondere 
kann der Debugger die aus den Arbeitsspeichern gelesenen Da- 
ten zur beliebigen Weiterverarbeitung auf einen Datentrager 

20 .(Festplatte, CDROW) speichern und/oder innerhalb e'ines Netz- 
werkes (wie Ethernet) ablaufen. 

Der erf indungsgemafie Debugger kann zudem gemaB DE 101 29, 
237.6-53 innerhalb einer Entwicklungsumgebung mit anderen 
25 Werkzeugen und insbesondere auch Debuggern kommunizieren; wo- 
bei in einer bevorzugten Ausgestaltung die Steuerung und/oder 
Definition der Debugparameter von einem anderen . Debugger aus 
ubernommen werden kann. Ebenso kann der Debugger die von ihm 
generierte Debug- Information einem anderen Debugger zur Ver- 
30 fugung stellen und/oder von diesem dessen Debug-Inf prmation 
erhalten. 
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Insbesondere das Feststellen des Auftretens von Breakpoints 
und/oder (Vor) Bedingung ist , durch einen anderen Debugger bzw. 
den Einheiten, die dieser andere Debugger debugt, durchfuhr- 
bar. Der erf indungsgemalie Debugger und die , VPU reagieren dann 
eritspre.chend. 

Der andere Debugger kann insbesondere der Debugger eines mit 
einer VPU gekoppelten anderen Prozessors (CT, bzw . . ARC bei 
Chameleon, Pentium, AMD usw.) sein. 



Insbesondere kann der andere Debugger auf einem der VPU zuge- 
ordneten und/oder gekoppelten Prozessor ablaufen und/oder der 
zugeordnete Prozessor der DB sein/ beispielsweise eine CT • 
bzw. ARC bei. Chameleon. In einer besonders bevorzugten Ausge- 
15 staltung kann der zugeordnete Prozessor ein Host-Prozessor 
sein, wie beispielsweise in der 60/317 , 876 ■ und/oder der DE 
102 06 856.9 beschrieben. 



20 5. Bewertung der Methoden 

Die Methode A ist erheblich zeit- und ressourcenintensiver 
als die Methode B, bei der kaum zusatzliche Hardware erfor- 
derlich ist und zudem.ggf. das zeitaufwendige .Auslesen der 
25 Debug-Inf ormation vom Start der. Applikation an entfallt . Da- 
her ist Methode B grundsatzlich yorzuziehen. Fiir Compiler 
nach DE 101 39 170.6 und deren Zusatzanmeldungen ist die Me- 
thode' B eindeu.tig zu' praferieren. 

30 Es wurde erkannt, dafi insbesondere die Verwendung beider Me- 
thoden A und B gemeinsam zu den besten und transparentesten 
Debuggingergebnissen- f iihrt . Insbesondere kann je nach Tiefe 
des zu debuggenden Fehlers zunachst unter . Zuhilf eriahme der 
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schnellen Debuggingmethode B debuggt werden -und nach hinrei- ' 
chende Lokalisierung des Fehlers sodann per Methode A die De- 
tails in der "Tiefe" analysiert werden. 



6. Mixed Mode Debugger 

Bei der Anwendung der besonders bevorzugten Methode B kann es 
zu dem Problem- kommen, dass die in den Speichern befindliche 
sichtbare Information nicht hinreichend ist. 

Typischerweise kann ein detaillierteres Debugging folgender- 
massen erfolgen: ■ 

a) Die sichtbare Debuginf ormation (PREINFO) vor der Konfigu- 
ration einer einen Breakpoint enthaltenden Konf iguration 
wird gesichert. Bei Auftreten eines ' Fehlers bei .dem Bre- 
akpoint wird die dann sichtbare Debuginf ormation (POSTIN- 
FO) gesichert. Basierend auf der PREINFO Information wird 
ein Software-Simulator gestartet, der die zu debuggen- 

de (n) Konf iguration (en) simul'iert.- Der Simulator kann da- 
bei jeden Wert innerhalb der PAEs "und der Bussysteme be- 
stimmen und (ggf . auch graphisch und/oder textuell) aus- 
geben, wodurch ein detaillierter Einblick in den Ablauf 
dies Algorithmus zum Zeitpunkt des Auftretens des Fehlers 
erreicht wird. Insbesondere ist es moglichy die jeweils 
simulierten Werte mit den Werten von POSTINFO zu verglei^ 
cheh, urn Differenzjsn schnell zu erkennen. 

b) Die sichtbare Debuginf ormation vor einem Breakpoint wird 
gesichert. Bei Auftreten eines Breakpoints wird basierend 
auf dieser Information ein Sof tware-Visuailisierer gestar- 
tet. Der zu debuggende Baustein wird nunmehr in einem 
Single-Step Verfahren betrieben, das das Auslesen samtli- 
cher relevanter Daten nach Methode A ermoglicht. Diese 
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Daten konnen nunmehr entweder direkt (ggf. auch graphisch 
und/oder textuell) ausgegeben werden und/oder an einen 
Simulator weitergeleitet werden, (lessen Simulation sodann 
auf den detaillierteren Daten beruht/ und danach wie be- 
kannt ausgegeben werden. 



6 . 1 Vorteile eines. Mxxed-Mode-Debuggers 

Der Mixed-Mode-Debugger . ermoglicht die detaillierte Analyse 
der Ablaufe innerhalb eines Bausteines. Durch- die Moglichkeit 
gemali Methode B, bis zu. einem gesetzten Breakpoint mit voller 
Geschwindigkeit zu arbeiten und danach ggf. anzuhalten, zu 
verlangsamen und/oder ggf. in einen Single-Step-Modus zu ge- 
hen, wird das Debugging zeitef f izient , wodurch das T,esten 
grofier Datenmengen und/oder komplexer Algorithmen ermoglicht 
wird. Das bevorzugte Aufsetzen eines Simulators nach dem Auf- 
treten des Breakpoints atif Basis der aktuellen Daten und Zu- 
stande ermoglicht einen genauen Einblick in die Hardware. So- 
fern der Zeitaufwand fiir die Simulation zu hoch ist und/oder 
die 100% Ubereinstimmung des Simulators mit der Hardware 
fraglich ist, ermoglicht das Zurucklesen von Daten im Single- 
Step-Modus nach Auftreten eines Breakpoints ^gemali Methode A 
Oder entsprechend des Kontext-Switch Verfahrens nach DE 102 
06 653.1 und DE 101 39 170.6 ein 100% korrektes Debugging des 
Algorithmus und/oder auch der Hardware selbst. 



7 , BeschreiJbung der Flgruren 



Figur 1 und 2 entsprechen der Patentanmeldung DE 101 '39 
170.6. pie unterschiedlichen Ansatze der Methoden A und B 
wurden in' die Figuren eingezeichnet (A, B) 
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Figur lb zeigt -eine Representation des endlichen Automaten 
durch eine refconf igurierbare Architektur nach P 44 16.881.0- " 
53 und DE 196 5,4 846.2-53 (DE 196 54 846.2-53, Fig. 12-15). 
Das kombinatorischen Netz aus Figur la (0101) wird durch eine 
Anordnung von PAEs, 0107 ersetzt (0101b). Das Register (0102) 
wird durch einen Speicher (0102b) ausgefuhrt, der mehrere Zy- 
klen speichern kann. Die Ruckkopplung gemali 0105 erfolgt 
durch 0105b. Die" Eingange (0103b bzw. 0104b) sind Equivalent 
0103 bzw 0104. Der direkte Zugriff auf 0102b kann ggf . durch 
einen Bus durch das Array 0101b realisiert werden. Der Aus- 
gang 0106b ist wiederum Equivalent 0106. 

Figur 2 zeigt die Abbildung eines endlichen Automaten auf ei- 
ne rekonfigurierbare Architektur 0201 (x) reprasentieren das 
koiribinatorische Netz (das t entsprechend Figur lb als PAEs" aus- 
gestaltet sein kann) . Es. existiert ein oder mehrere Speicher 
fur Operanden (0202) und ein oder mehrere Speicher fur Ergeb- 
nisse (0203) . Zusatzlich Daten Ein-/Ausgange gem. 0103b, 
0104b, 0106b) sind der Einfachheit haib>er nicht dargestellt.. 
Den Speichern zugeordnet ist jeweils ein Adressgenerator 
(0204, 0205) . 

Die Operanden- und Ergebnisspeicher (0202, 0203) sind physi- 
kalisch oder virtuell derart miteinander verkoppelt, dali bei- 
spielsweise die Ergebisse einer Funktion eirier anderen als 
Operanden dienen konnen und/oder Ergebnisse uind Operanden ei- 
ner Funktion einer anderen als Operanden dienen konnen. Eine 
derartige Kopplung kann beispielsweise durch Bussysteme her- 
gestellt werden oder durch eine (Re) Konf iguratibn, durch wel- 
che die Funktion .und Vernetzung der Speicher mit den 02.01 neu 
konfiguriert wird. 
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Pigur 3 zeigt eine mogliche sc'heinatische StruktUr des Debug-, 
gings nach Methode B. Es sei insbesondere " beispielhaf t auf 
die Figuren 19, 20, 21 der Patentanmeldung DE 199 26 538.0 
verwiesen, in welcher die Grundlage der Speicher beschrieben 
5 ist. Die DE 199 26 538,0 wird hiermit zu Of f enbarungszwecken ■ 
vollumf anglich eingegliedert . 

0101b und 0102b ist wie bereits besphrieben dargestellt. Zu- 
satzlich ist eine -externer- Speichereinheit dargestellt 
10 (0302), der moglicherweise Mhnlich DE 199 26 538.0 an 0102b 
angeschlossen .(0307) sein kann. Es soil besonder's darauf hin- 
gewiesen werden, dafl sowohl 0102b als auch 0302 externe oder 
interne Speichereinheiten sein konnen. Ebenfalls soil eine 
Speichereinheit als mindestes ein Register, eine Menge von 
15 ■ Registern. oder ein Speicher (RAM, .Flash, b.a.) oder Massen- . 
speicher (Festplatte, Band, o.a.) definiert sein. 

Die debuggende Einheit 0301 kann Breakpoints' innerhalb 0101b 
setzen (0303), auf Basis derer der eigentliche Debug Vorgang 
20 ausgelost wird. Durch das : Erreichen . exnes Breakpoints wird 
eine Information (0304) an- 0301 gesendet, die den Debug Vor- 
gang startet; zugleich werderi auch alle 0101b interenen Vor- 
kehrungen zum Debuggen' (z.B. ein Anhalten und/oder Verlangsa- 
• men des Taktes) ausgelost . Alternativ kann auch durch 0301 
25 die Information generiert und an 0101b gesendet werden. 

. tfber 0305 und/oder 0306 kann 0301 auf die Daten und/oder Zu- . 
,stande aus dem Speicher 0102b und/oder dem Speicher 0302. zu- 
greifen. Der Zugriff kann zum Beispiel 

.1. durch eine Speicherkopplung (Block-Move, d.h. kopieren 
30 der Speicher in einen andereni von 0301 kontrollierten 

Bereich) , 
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2. clurch eine Leitung (serielle oder parallele Leitung, 
uber die ein oder mehrere Speicherbereich (e) ubertragen 
wird/werden, . z.B. JTAG) , ^ 

3. Buskopplungen gleich welcher Art (die Speicher werden 

5 ahnlich eines DMA- Verf ahren arbit'riert und von 0301 ver- 

arbeitet ) " 
■erfolgen. 

Als Beispiel wurde eine Figur aus der.DE 199 26 538.0 ge- 
ld wahlt. Es soil ausdrucklich darauf hingewiesen werden, dafi 

grundlegend jedes Speicherverf ahren- und jede Speicherkopplung 
(Stack, Random-Access, FIFO, usw.) entsprechend bearbeitet 
werden kann. *, 

15 Die Figuren 4a und 4b zeigen weitere moglichen Ausgestaltun- 
gen und wurden" aus der Patentanmeldung DE 102 06 856.9 ent- 
nomihen, die zu Of f enbarungszwecken yollumf anglich eingeglie- 
dert ist. 

20 Der Aufbau einer bes'onders bevorzugten" VPO ist in Figur 4a 

dargestellt. Vorzugsweise hierarchische Konf igurationsmanager 
(CT's) (0401) steuern und verwalten eine Anordnung von rekori- 
f igurierbaren Elementen (PACs) (0402). Den CT's ist ein loka- 
ler Speicher fur die 1 Konf igurationen zugeordnet (0403) . Der 
25 Speicher verfiigt weiterhin liber ein Interface (.0404) zu einem 
globalen Speicher, der die Konf igurationsdateh zur Verfugung 
stellt. Ober ein Interface (0405) sind die Konf igurationsab- 
lauft steuerbar. Ein Interface der rekonf igurierbaren Elemen- 
te (0 4 02) zur Ablauf steuerung und Ereignisverwaltung (04 0 6) 
30 ist vorhanden, ebenso-ein Interface zum Datenaustausch 
(0407). Beipielsweise kann eine der CT.'s als DB agieren. 
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Figur 4b zeigt einen Ausschnitt aus einem beispielhaf ten CPU- 
System, beispielsweise einem DSP des ' Types C6000 von' Texas 
Instruments (0451). Dargestellt sind Prpgrammspeicher (0452) , 
Datenspeicher (-0453), beliebige Peripherie (0454) und EMIF 
5 (0455) . Uber einen Speicherbus (0456) und einen Peripheriebus 
(0457) ist eine VPU als Coprozessor integriert (0458). Ein 
DMA-Kontroller (EDMA) (0459) kann beliebige DMA-Transfers, 
beispielsweise zwischen . Speicher (0453) und VPU (0458) Oder. 
Speicher (0453) und Peripherie (0454) durchfiihren. In diesem 
10 Beispiel kann 0451 als DB arbeiten und insbesondere ' auch der 
erf indungsgemafie Debugger mit dessen Debugger gekoppelt 
und/oder in diesen integriert sein. 

Figur 5a zeigt einen beispielhaf ten Hardwareaufbau, der zum 
15 Debuggen von rekonf igurierbaren Prozessoren behutzt werden 
kann. Hierzu wird ein gepipelinter Konf igurationsbus 0501 
verwendet, ahnlich dem aus DE 100 28 397.7 bekannten. Die 
Pipeline ist uber mehrere Registerstuf en (0502) in • horiz-onta- 
ler und/oder- vertikaler Richtung aufgebaut, urn hohere Takt- 
20 frequenzen zu erreichen. Der gepipelinte Konf igurationsbus 

fiihrt zu den zu konf igurierenden Elementen ,(?AEs) (0503), urn 
diese mit Konf igurationsciaten zu versorgen. 

Figur 5b zeigt beispielhaft die erf orderliche Erweiterung ge- 
25 mafl'der vorliegenden Erfindung. Jede. Registerstuf e (0502) de- 
krementiert den Zahlenwert (LATVAL) zum Ausgleich der Latenz- 
zeit urn 1 (angedeutet durch -1) . Ebenso dekrementierf jede 
PAE (0503) , die bereits eine Taktsteuerinf ormation erhalten 
hat, diese pro Takt urn 1 (angedeutet durch -1/T) . Auf die 
30 PAEs und insbesondere deren internen Register kann nunmehr 

nicht nur schreibend," sohdern auch lesend zugegriffen werden, 
z.B. aber eine besondere Steuerleitung (RD) , urn Debugdaten 
auszulesen. Zu schreibende und gelesene Daten 'durchlsuf en in- 
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dieserh Beispiel das Bussystem durch das Array' aus PAEs von ' 
links nach rechts und in der untersten Zeile in Riick- 
wartsrichtung. Der Konf igurationsbus ist weiterhin uber Regi- 
sterstufen (0505) pipelineartig zuruckgef uhrt (0504) . In die- 
sem Beispiel kann eine. ubergeordnete Einheit (CT/Ladelogik, 
Hostprozessor) (0506) ebenso lesend und schreibend auf den 
Bus zugreifen, wie ein dediziertes Testinterf ace (0507). Das 
Testinterface kann einen eigenen Testkontroller aufweisen und 
insbesondere kompatibel zu einem oder mehrern marktgangigen 
Testschnittstellen sein (z.B. JTAG, Tektronix, Rhode&Schwarz, 
etc) . Die Auswahl der bussteuernden Einheit erfolgt uber eine 
Multiplexer/Demultiplex'er^Einheit (0508), In (0509 in Klam- 
mern urid kursiv dargestellt) oder vor den Einheiten 0506 und, 
0507 kann eine Schaltung zur Ruckrechung der Herkunf tsadresse 
(0509) von Debugdaten> .die iiber 0504 eintreffen, vorgesehen 
sein. Die Adressberechnungen .innerhalb des aufgezeigten Sy- 
stems geschehen. wie folgt: Zunachst wird die. Adresse durch 

0506 oder 0507 am Bus 0501 angelegt. Die Adresse wird ahnlich 
der Verarbeitung der Zahlenwerte (LATVAL) zur Latenzberech- ' 
nung in jeder Registerstuf e (0502 und '0505) dekrertientiert . 
Sobald die Adresse gleich 0 i(3t, wird die -nach. der Register- 
stuf e liegende PAE selektiert. In der nachf olgenden Register- 
stuf e wird die 1 Adresse negativ, so daiJ keine weiteren PAEs 
mehr aktiviert werden. Sofern Daten aus einer PAE gelesen 
werden, werden diese zusammen mit der Adresse zuruckubertra- 
gen. Die Adresse wird dabei in jeder Registerstuf e weiter de- 
krertientiert. Eine Ruckrechnung in 0 509 der bei 0 50 6 und/oder 

0507 zusammen mit den Debugdaten eintre'f f enden Adressen ist , 
nunmehr durch eine einfache Addition moglich, indem die £n- 
zahl der dekrementierenden Registerstuf en zu dem eintreffen- 
den Adresswert hinzuaddiert werden. Es soil angemerkt s^ein, ■ 
dass die Registerstuf en 0502 in Figur 5b leicht unterschied- 
lich gegeniiber den Registerstuf en 0502 in Figur 5a ausgestal- 
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tet sind.. In Figur 5b weisen diese namlich zusatzlich eine 
Schaltung ( 2 . B . Multiplexer) zu AusVahl der weiterzuleitendeh 
Daten auf , der entweder die Daten des Busses 0501 weiter- 
. schaltet oder den Ausgang der zugeordneten PAE (0503) und so- 
mit die DebugDaten. Zur Ansteuerung der' Schaltung kann das 
Auftreffen des Adresswertes gleich 0 dienen. 

Es wird nochmals darauf hingewiesen, • dafi das dedizierte Te- 
stinterface (0507) den Industries tandards entspricht . . Es kann 
zu Tests wahrend des Sof tware-Debug-Vorgang.s eingesetzt wer- 
den und/oder zu Test wahrend des Zusammenbaus von Hardware- 
komponenten und -systemen (z . B . dem Zusammenbau der Schaltun- 
gen auf der Platine) und/oder zu Funktionstests des Halblei- 
terbausteins (Chips) im Rahmen der Halbleiterf ertigung . Ins-- 
besondere dadurch kann dieubliche Scan-Chain zum Test der 
Register" wahrend des Funktionstests des Halbleiters entf alien 
oder zumindest entsprechend minimiert- werden, da dann nur . die 
Register durch die Scan-Chain geftihrt werden mussen, ' die 
nicht vom Bussystem (0501) ansteuerbar sind. 

Ebenfalls wird besonders darauf hingewiesen, . daB das in Figur 
5. erlauterte Verfahren keinesfalls auf. die Anwendung bei Kon- 
figurationsbussen beschrankt ist. Gewohnliche Datenbussysteme 
konnen ebenso zu den unterschiedlicheri vorab aufgezahlten 
Test- und Debugging-Ze.itpunkten und -arten verwendet werden. 
Insbesondere sei in diesem Zusamxnenhang auf das in der DE 197 
04 74214 beschriebene Datenbus system hingewiesen. Die DE 197 
04 742.4 ist hierzu zu Of f enbarungszwecken vollumf anglich 
eingegliedert . Die in Figur 5 beschriebenen Verfahren konnen, 
ftir eihen Ingenieur mit gewohnlichen technischen Kenntnissen 
leicht nachvollziehbar ebenso auf die DE 197 04 -742.4 ange- 
wendet werden. 
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Bin Mischbetrieb unterschiedlicher Bussysteme, wie Konfigura- 
tionsbussystemen, Datenbussystemen . nach DE 197 04 742.4 und 
gewflhnlichen Datenbussystemen 1st desweiteren. grundsatzlich 
moglich, Dazu k5nnen mehrere Testinterf ace vorgesehen se.in, 
Oder wie technisch bevorzugt die Multiple- 

xer/Demultiplexerstufe. (0508) auf eine Mehrzahl .von Bussyste- 
men (n x 0501,, n x 0504) ausgelegt werden. 

AbschlieiJend soil noch besbnders erwahnt . sein, dass durch die 
Ruckfuhrung .des Bussystems nach Figiir 5b auch die in die PAEs 
zu schreibenden Konf igurationsdaten zurtickgefuhrt werden. Un- 
ter Zuhilfenahme der Adressruckrechung (0509) und der zuruck- 
gefuhrten Statusleitung RE J , die nach DE 100 28 397.7, DE 198 
07 872.2, DE 196 54 593.5-53 eine Zurtickweisung der Konfigu- 
rationsdaten anzeigf, kann auf die Verwehdung der Konfigura- 
tionszwischenspeicher-FIFOs naOh DE 100 28 397.7 Figuren 8 
und' 9 (0805/ 0903.) verzichtet werden, da deren Funktionalitat 
nunmehr vollumfanglich uber das' beschriebene Bussystem. abge- 
bildet wird. 



8. Beqariffsdefinition. 
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lokal relevanter Zustand 



Zustand, der nur innerhalb einer 
bestimmten Konf iguration relevant 
ist- 



global relevanter Zustand Zustand/ der in mehrerert Konfigu- 

ratio.nen relevant ist uhd zwi- 
schen den Konf igurationen ausge- 
tauscht werden niufl i • 



relevanter Zustand 



irrelevanter Zustand 



Zustand, der innerhalb eines Al- 
gorithms zur korrekten Ausfuh- 
rung dessen benotigt wird und so- 
mit durch den Algorithmus be- 
schrieben ist und verwendet wird. 

Zustand, der fur den eigentlichen" 
Algorithmus ohne Bedeutung ist 
und au'ch nicht im Algorithmus be- 
schrieben ist, der jedoch von der 
au'sftihrenden Hardware implemen- 
tierungsabhangig benotigt wird. 
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Titel: Verfahren zum Debugger! rekonf igurierbarer 

Architekturen •■ 



Patentanspruche , 

1. Verfahren .zum Debugger! von rekonf igurierbarer Hardware, 
.dadurch gekennzeichnet , dafl samtliche notwendige Debug- 
information je {Configurations zyklus in einen Speicher ge- 
schrieben werden, der dann vom Debugger ausgewertet wird. 

2 . Verfahren nach dem vorhergehenden Anspruch, dadurch ge- 
kennzeichnet, dafl wahrend des Debug-Vorganges nach Auf- 
treten einer Debug-Bedingung, gemafi welcher Information 
uber die zu debuggende Konfiguration benotigt wird, eine 
Konfiguration geladen wird, mittels welcher die in den 
Speicher geschriebenen Debug-Inf orma'tionen ausgelesen und ; 
insbesondere in eine ' Debug-Einheit oder Debug-Konf igura- 
tion geschrieben werden. 

3. Verfahren, nach einem der, vorhergehenden Anspriiche, ' da- 
durch gekennzeichnet, dafl eine zu debuggende Konfigurati- 
on, vor dem Ablauf des Debugging derart verandert wird, 
dafl bei normaler, nicht-debuggender Ausfuhrung nicht er- 
forderliche Information ineihem Speicher abgelegt wird. 

I. Verfahren nach einem der vorhergehenden Anspriiche, da- 
durch • gekennzeichnet, dafl zum Auslesen die Taktfrequenz 
zumindest verlangsamt oder angehalten wird und/oder eine 
taktweise Abarbeitung der zu debuggenden Konfiguration 
Schritt fur Schritt erfolgt. 
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Verfahren -nach einem der vorhergehenden Anspriiche, da- 
durch gekennzeichnet, daJi die zu debuggende Kohf iguration 
nach Auslesen der relevanten Information oder nach davor- . 
liegender Information simuliert wird. 

Vorrichtung mit einem Feld konf igurierbarer Elemente, 
insbesondere grobgranularer logischer und/oder arithmeti- 
scher Einheiten sowie einem Debug-Mittel zum Debuggen von 
Programmen, Programmteilen oder auf dem Array auszufiih- 
renden komplexen Operationen, dadurch gekennzeichnet , dafi . 
das Debug-Mittel ein Speichermittel zur -Speicherung von 
fiir das' Debugging relevanten Inf ormationen wahrend oder 
am Ende eines . Arbeitsschrittes des Feldes konf igurierba- 
rer. Elemente umfafit, wobei das Speichermittel zum Debug- 
ging auslesbar- ist. 

Vorrichtung nach dem vorhergehenden Anspruch, dadurch ge- 
kennzeichnet, dafi das Speichermittel als Dual-Ported-RAM 
mit .einem ersten Eingang fiir abzuspeichernde Information 
aus dem Prozessorfeld und einem zweiten Eingang zum Aus- 
lesen der - Information in ein Analysemittel ausgebildet 
ist, , ■ 
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Titel: Verfahren zum Debuggen rekbnf igurierbarer 

Architekturen 



5 Zusammenf assung 



Die Erfindurig betrifft ein Verfahren zum Debuggen von rekon- 
f igurierbarer Hardware. Hierbei,i>st u..a. vorgesehen, dafi . 
10 samtliche notwendige Debug-Inf ormation je Konf igurationszy- 

klus in einen Speicher geschrieben wirdV der dann vora Debug- 

♦ 

ger ausgewertet wird. , 



(Fig. lb) 
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